An Integrated Development Environment for Java Card 1

syntax (Metal) Unparsing spec. (PPML) Dynamic semantics (Typol) Java Card Editor APDU Format Extractor Java Card Simulator Format analysis (Typol) Fig. 3. The relation between speci cations and generated tools. 3.2 Tool Generation All the above mentioned tools were created using the Centaur system. Figure 3 illustrates the relationships between the developed speci cations on the one hand, and the generated tools on the other. To obtain the structure editor, we have speci ed a Java Card parser and a pretty printer or unparser. The parser speci cation de nes the concrete and abstract syntax of the Java Card language as well as tree building functions. It is written using the Metal formalism which permits the concrete and abstract syntax to be speci ed simultaneously. This speci cation is then used to automatically generate a parser. The parser is responsible for translating Java Card source (text) into an abstract syntax tree which is how Java Card applets are represented inside the environment. The PPML speci cation is then used to translate an abstract syntax tree back to text, e.g. for display purposes within the editor, or for storing the Java Card program in a le. The central part of the Java Card simulator is the dynamic semantics of Java Card, speci ed in Natural Semantics using Typol [16]. Typol is the language used to specify semantics in Centaur. It is a typed, declarative, logic language with backtracking, uni cation and pattern matching mechanisms (see section 6 for an example). The Java Card semantics is speci ed on the level of the abstract syntax, and thus it also needs to refer to the Java Card abstract syntax speci cation. For studying the behaviour of an applet during execution, it is possible to view important runtime structures. These structures are represented internally as trees. Thus PPML is used to specify the unparser. 7 The APDU format extractor also works on the abstract syntax tree of a Java Card applet. In addition, it uses data structures speci c to the analysis task, which are again speci ed using Metal and PPML. The extractor itself is written in Typol. 4 The Java Card Structure Editor This section describes the features of the editor. We illustrate by explaining how to write a small Java Card program, which also will be used as Ariadne's thread in the following sections. Our editor is dedicated to the Java Card language. It prevents the developer from making errors w.r.t. the general Java syntax (e.g. a semicolon or a brace missing), but also from making errors related to the speci cities of Java Card (e.g. using the char, long, double, float primitive types, multidimensional arrays, or the synchronized, volatile, transient keywords) [10]. These latter errors would otherwise only be discovered when converting class les into CAP (Converted Applet Program) les since standard Java compilers are used to compile Java Card programs. Anyone who uses our editor will only encounter errors related to the static semantics (e.g. unde ned variables, type errors) when compiling, and no errors at all during the conversion stage. Applets are stored as plain Java Card text les. This makes it easy to import existing Java Card applications into our environment, or to use traditional text editors for development should that be desired. Internally, the applet being edited is represented as an abstract syntax tree. Syntax colouring is made possible by specifying di erent styles (font, size, colour) in the unparsing rules. Note that, unlike a conventional text editor like Emacs which does not do a proper parsing, we are sure that the colours will always be correct. Moreover the formatting scheme (i.e. indentations, where the braces are set) is the same for all the Java Card programs ensuring consistency regardless of author. The editor provides two ways for writing source code: free text editing or syntax-directed editing. In the rst mode, the editor behaves like a normal text editor, but the written part is parsed when this mode is exited. Thus, only syntactically correct program fragments can be inserted into the abstract syntax tree. The other mode facilitates the development by displaying the valid syntactic constructs which can replace the selected part of the code in a context-sensitive menu. When any of these constructs is selected, its structure replaces the selected part and only the placeholders need to be lled in by the developer (a placeholder starts with a dollar sign). If the placeholder is for 8 Fig. 4. Start menu and syntax-coloured applet skeleton. an identi er, the completion mechanism can be used to avoid writing the full name of an identi er which occurs somewhere else in the program. When starting writing a Java Card program from scratch, a menu allows either an applet pattern or a class pattern to be inserted into the empty editor window; see gure 4. If the developer chooses the applet pattern in the menu, the skeleton of an applet is displayed. This skeleton contains the structures of the applet constructor and the main methods i.e. process, install, select, deselect and getShareableInterfaceObject. The install method already contains the creation of the applet object and the registration call to the JCRE. Thus, the developer only needs to ll in the placeholders. Figure 5 shows a menu of the available block statements and the result of selecting and inserting the if-pattern into an applet being developed. This is a simple purse applet, which we are using as the running example in the rest of the article. The complete program can be found in appendix A. The services provided by this applet are deposits, withdrawals, and balance inquiries. See Chen [7] for an introduction to how to write Java Card applets. Finally, also note that comments are handled. They are seen as decorations in the abstract syntax tree and correctly handled by the pretty printer (in green on lavender background). 5 The CAD Simulator The CAD simulator gives the user the possibility to interactively test applets. It provides a graphical user interface which allows both generic and application-speci c APDUs to be constructed and sent to the Java Card sim9 Fig. 5. Block statement menu. CLA INS P1 P2 Lc data Le CLA Command class Lc Length of data eld (optional) INS Instruction data Application-speci c data (optional) P1,P2 Parameter 1, 2 Le Length of data eld in response (optional) (a) Command APDU data Sw1 Sw2 data Application-speci c data (optional) Sw1, Sw2 Status words indicating command result (b) Response APDU Fig. 6. The general layout of APDUs. ulator. It also allows the returned response APDUs to be inspected. An APDU log records all sent and received APDUs. The CAD simulator allows these sessions to be stored and later re-used in order to undertake regression testing. While the basic APDU layout and some commands are standardised ( gure 6), any particular application necessitates the de nition of application-speci c commands. Since an APDU is just a byte sequence, it would in principle be enough if the CAD simulator simply allowed arbitrary byte sequences to be assembled and sent. But that would clearly be rather inconvenient for the user under normal circumstances. It is far easier to just specify the contents of an APDU and let the simulation environment take care of the packing (and unpacking) details. However, this means that the CAD simulator needs to be told about the details of application speci c APDUs, such as what command names there are, 10 Applet Name AID Commands [Command] Name CLA INS Lc Arguments Le Response [Argument] Name Position Length Fig. 7. The structure of an applet description. Square brackets indicate a list. the command number for each one, the names and types of any arguments (in the data eld), etc. To make it possible to use the CAD simulator without rst having to provide a separate speci cation of the application speci c APDU formats, we have developed a tool, the APDU format extractor, which extracts this information from an applet by static analysis. The extraction scheme works reasonably well since a Java Card applet usually is written in a very stylized way (there is always a method process which does the initial command decoding, the basic layout of the APDUs is standardised, etc.). Thus a developer typically just has to write the applet code, or indeed, get code from somewhere else, and the CAD interface will automatically adapt itself to the applet (or applets) in question. The results from an analysis can be saved to avoid having to re-analyse known applets. Figure 7 shows a somewhat simpli ed structure of the applet descriptions returned by the format extractor. For the purpose of the CAD simulator, an applet is described by its name and AID (applet ID, for selecting the applet), and descriptions of the accepted commands and their associated formats. The format extractor works by symbolically executing the applet code, keeping track of data dependences and constant and variable names in the process. The APDU extraction process consists of four steps : (1) Statement ltering (2) Command identi cation (3) Command APDU arguments analysis (4) Response APDU analysis The APDU format extractor is written in Typol, using inference rules and axioms for each step of the extraction process. Step 1 transforms the program in order to keep only the statements that 11 instructions |call(Util.arrayCopy,SrcBuffer, SrcOff, DestBuffer, DestOff, Length) -> arrayAssign((SrcBuffer, SrcOff,Length ), (DestBuffer,DestOff,Length)).instructions) Fig. 8. Extraction of the arrayCopy statement. Lookup(instructions |bufferAccess is APDUIdent.getBuffer()[ISO.OFFSET_INS]) Intersection(|INS, GetValue(Command)-> InsForThen) UpdateCommandsList( AppletSpecification |(CLA, InsForThen), GetName(Command) -> NewAppletSpecification) Intersection(|INS, Not(GetValue(Command)) -> InsForElse) ----------------------------(CLA, INS), instructions, APDUIdent |if (bufferAccess == Command), AppletSpecification -> (CLA, InsForThen ), (CLA, InsForElse), NewAppletSpecification Fig. 9. Analysis of the conditions concerning the second byte of the APDU bu er. we are able to analyse and to nd important method calls such as calls inside the current class and calls to system methods like arrayCopy. Figure 8 shows how this ltering is done in Typol for a call to arrayCopy: given a list of instructions, each statement is considered in sequence, to build a new list of instructions. Here the pattern-matching on the one hand focuses on invocation (call statement) and on the other hand imposes the name of the method (Util.arrayCopy). Parameters of the considered statement (SrcBuffer, SrcOff, DestBuffer, DestOff, Length) are re-used to build the instruction arrayAssign which is then stored in the resulting list. Array copying is important because the APDU bu er is an array, and array operations may thus concern the APDU. Step 2 analyses the conditions of if-statements in order to nd accesses to the rst and second byte of the APDU bu er. These two bytes (designated as CLA and INS ) are used to distinguish between di erent instructions. A list of CLA and INS bytes being tested for are extracted from the condition of each if-statement. The if-statements are then transformed into blocks labelled with the corresponding CLA and INS for further analysis. Moreover, this step creates the list of pairs (CLA , INS ) which are valid for the given applet being tested for) and the list of pairs (CLA , INS ) which are invalid (which cause a CLA_NOT_SUPPORTED or INS_NOT_SUPPORTED exception). Figure 9 gives one of the main rules of the second step which analyses the condition of an if-statement, updates the list of existing commands, and returns the corresponding CLA and INS sets. In this rule, Lookup is a function which performs a lookup in a set of statements and follows dependences graph to determine whether two expressions are equal (after evaluation) or not. GetName is a function that takes an expression and returns a string in order to give a name to the corresponding statement (for example when the expression is an identi er it returns the identi er name). Step 3 examines accesses to the APDU bu er and updates the list of arguments a command APDU should contain. The fth byte of the APDU is the length 12 public class MyApplet extends Applet { final static byte SendValue = 0x50; final static byte My_CLA = 0xE5; … public void process(APDU apdu) throws ISOException { byte[] buffer = apdu.getBuffer(); if (buffer[ISO.OFFSET_CLA] == My_CLA) if (buffer[ISO.OFFSET_INS] == SendValue) { apdu.setIncomingAndReceive(); short Value = Util.getShort(buffer, 5); } ... } } Command CLA: E5 INS: 50 Parameters Parameter 1 Length: 2 Position: 5 Name: « Value » Name: «SendValue» Fig. 10. Illustration of the extraction process. of the data eld which itself starts at the sixth byte. The APDU extractor considers the data eld as a list of arguments of di erent lengths and positions, which are to be identi ed by the analysis. When an access to the APDU bu er is encountered, the position (given by the o set of a call to arrayCopy, getShort, or similar), the length (2 for a getShort method, for example), and the name to be associated with the thus identi ed argument can normally be determined. Then the list of arguments of the corresponding commands has to be updated. The currently analysed block (corresponding to the nearest if-statement) contains the list of commands concerned by the analysed bu er access. Step 4 is similar to step 3 and determines the structure of the response APDU. Figure 10 gives an example which schematically illustrates the principle behind the extraction process. See Henrio [14] for further details. It could happen that the analysis carried out by the format extractor fails due to an applet not being su ciently stylized. In that case, the user can create the applet description manually by using an editor. The CAD simulator also allows standard applet installation and selection APDUs to be sent, as well as arbitrary APDUs assembled from scratch. The latter is useful for sending non-conforming APDUs in order to test that an applet handles invalid commands correctly, for instance. Furthermore, there is an option to simulate card withdrawal, which optionally can be combined with saving the state of the running card. The card simulator can be initialized from such a saved state. When applied to the Purse example, the extractor determines that the name of the applet is Purse, and that this applet accepts three commands: PURSE_DEPOSIT, PURSE_WITHDRAW, and PURSE_BALANCE_CHECK with instruc13 Fig. 11. The CAD simulator command selection window. Fig. 12. The CAD simulator command send window and the APDU log. tion numbers 1, 2, and 3 respectively. PURSE_DEPOSIT is found to have one short (2-byte) argument amountOfDeposit at position 5, and PURSE_WITHDRAW is similarly found to have one short argument amountOfWithdraw at position 5. Finally, the extractor determines that all commands return a short result purseTotal, i.e. the resulting balance. The result of the analysis is sent to the CAD simulator which opens a window which allows one of the three identi ed commands to be sent to the applet; see gure 11. Once one of these commands has been selected (by clicking on it), a second window pops up which allows any parameters to be lled in prior to sending the complete APDU to the applet; see gure 12. Many of the numeric elds of this window (CLA , INS , etc.) are xed as they are given by the command in question and only present for information purposes. The window also shows the full details of the sent command APDU and, eventually, the received response APDU in the form of byte strings. Figure 12 shows the result once a deposit of 101 Euros has been made to an empty purse. Note that the resulting balance is 101 (0x0065) Euros. The gure also shows the APDU log which keeps track of all sent and received APDUs and allows them to be examined. 6 The Java Card Simulator The central part of the Java Card simulator is an executable speci cation of the dynamic semantics of the Java Card language [19]. It is expressed in Nat14 ural Semantics, small-step style, using Typol. Thus the semantic rules express the stepwise transformation of the abstract syntax tree of an applet into the nal result. The semantic speci cation is derived from a Java speci cation also developed within our group [2,3]. Almost the entire Java semantics has been re-used without changes to make it easy to pro t from further developments of it (or vice versa). As there is no concurrency on a Java card, the scheduler was changed [10]. There is only one active thread and a thread may only be activated when some special program points are reached. Furthermore, executable speci cations of Java Card APIs (i.e. speci cations of Java Card classes such as AID, APDU, APDUException, Applet, JCSystem) have been added. On the top, we have speci ed a minimal JCRE with the duties to receive command APDUs, select applets, dispatch commands APDUs between applets, and send response APDUs to the terminal. The principle of Typol rules is the following: inference rules and axioms are structured in sets, that deal with a same object (evaluateExpression for instance). Each rule P1 P2 ::: Pn P has a number of premises P1, P2, . . . , Pn and one conclusion P . If all premises are true, then the conclusion holds and the rule applies. Figure 13 shows some Typol rules from our Java Card semantics. They are concerned with giving the semantics of an if-statement. The rst rule says that an if-statement where the condition is not yet in normal form, is to be rewritten to an if-statement where the condition has been evaluated one step further by the rule evaluateExpression. The parameters ObjL1 and ClVarL1 (and variations) are the object list and class variable list, respectively, i.e. they represent the current global state of the Java machine. OThId is the id of the currently executing thread. The actual if-statement is embedded in what is referred to as a `closure' (constructed with the operator clr), which represents the rest of the computation for a thread (in some global state). In particular, a closure contains a list of instructions, of which the rst one is the current instruction. Other important parts of the closure are the object id (corresponding to this object), and an environment for local variable bindings. The two following rules state that an if-statement where the condition is in normal form (i.e. true or false), should be replaced by either the then-branch or the else-branch depending on the condition. It should be pointed out that the current semantics is incomplete in some respects. For example, it is a dynamic semantics which currently does not perform static type checking. As a consequence, overloading resolution is not handled completely accurately. However, since Java Card applets tend to be small and fairly simple, the current limitations have as yet not caused any major problems. 15 If_EvaluateExpression: evaluateExpression(ObjL1, ClVarL1, Env1, OThId, ObjId1, Mode |Expr1 -> ObjL1_1, ClVarL1_1, Env1_1, Expr1_1, InstL2, ThStatus) & appendtree(InstL2, insts[if(Expr1_1, Stat1, Stat2).InstL1], InstL3) ---------------ObjL1, ClVarL1, OThId |clr(ObjId1, Mode, MethName, Env1, insts[if(Expr1, Stat1, Stat2).InstL1]) -> ObjL1_1, ClVarL1_1, clr(ObjId1, Mode, MethName, Env1_1, InstL3), ThStatus ; provided diff(Expr1, true()) & diff(Expr1, false()); If_False: ObjL, ClVarL, _ |clr(ObjId, Mode, MethName, Env, insts[if(false(), _, ElseStatement).InstL]) -> ObjL, ClVarL, clr(ObjId, Mode, MethName, Env, insts[ElseStatement.InstL]), executing() ; If_True: ObjL, ClVarL, _ |clr(ObjId, Mode, MethName, Env, insts[if(true(), ThenStatement, _).InstL]) -> ObjL, ClVarL, clr(ObjId, Mode, MethName, Env, insts[ThenStatement.InstL]), executing() ; Fig. 13. Excerpts from the Java Card dynamic semantics speci cation. The formalisation of the JCRE covers the basic aspects of the runtime system such as loading and registration of applets, selection and deselection of applets, and the primitives necessary for communication with the runtime environment, i.e. the CAD simulator in our case. There is also support for saving and loading the state of a running card. This is used to simulate card insertion and withdrawal, but it is also useful for debugging since it makes it possible to get back to some interesting state without having to restart debugging from scratch, or if one simply would like to take a pause and continue from where one left o at some later point. When it comes to the APIs, there are two basic approaches. One possibility is to describe them in Java, somehow making use of built-in primitives where necessary. The API classes would then be loaded into the simulation environment prior to the loading of any applets. The other approach is to describe the semantics of the API classes and their methods directly in Typol. Basically, this means that there is a set of hard-coded rules for each method which describes what happens when the method in question is invoked. We have chosen the latter approach for the following reasons: If we implement some of the APIs in Java Card, all the corresponding code will be interpreted by Typol rules which would take much more time. This API code would also be visible during debugging, even though it can be expected to be reasonably correct (once released for applet development, not during the development of the API code itself, of course). It is natural and simple to let the API methods be the built-in primitives. Otherwise, it would be necessary to provide access to lower level primitives by some other means. Moreover, in that case, many of the API methods would not do more than just invoke such a primitive anyway. 16 Fig. 14. The Java Card simulator during execution of the Purse applet. Having the semantics of important methods directly available as Typol rules hopefully makes it easier to prove properties about the speci cation as well as individual applets. The speci cation of the Java Card APIs is not as yet complete. For example, the mechanisms for atomic transactions and object sharing, as well as the related API methods, are currently not in place. During simulation, the developer can follow the execution in detail at a selectable speed through a graphical user interface. It is also possible to stop (interactively or by setting breakpoints), single step, and continue. The breakpoint and single stepping facilities currently work at the level of the semantic rules, not at the level of the Java Card source code. This is suitable for debugging the Java Card speci cation, or for a user who would like to learn about the semantics of Java card, but it is not ideal for debugging applications. Improved debugging support in this respect is something which we plan to look into. Other features include textual browsers for inspection of variables and objects. Our Java environment [3] provides a dynamic, graphical view of the created object structures which would be useful also for the Java Card environment. This functionality could easily be carried over. Figure 14 shows the Java Card simulator executing the Purse applet just after having received an APDU requesting the deposit of 100 Euros. The large window is the main Typol debug window which shows the current rule. It is equipped with buttons for controlling the execution. The small window shows the value of the variable commandAPDU which has been selected in the main window. The shown value is the received command APDU: note the value 0x0064 = 100 in the APDU's data eld. 17 7 Conclusions and future workThis article described a Java Card programming environment which to a largeextent has been generated from formal speci cations of the syntax and seman-tics of Java Card. Through this approach, we were able to develop a set oftightly integrated tools with useful and novel functionality, such as the APDUformat extraction, at a high level of abstraction. The main features of theenvironment from a user perspective are:Java Card-speci c structure editor.CAD simulator which makes it easy to send and receive APDUs.Automatic extraction of the APDU formats from applet source code andautomatic adaptation of the user interface of the CAD simulator accord-ingly.Semantics-based Java Card simulator with facilities for monitoring the ex-ecution and important data structures.This makes the environment useful for applet developers, applet testers, andpeople wanting to learn about the Java Card semantics.Furthermore, the fact that a formal, dynamic Java Card semantics is the ba-sis of the simulator, means that it has been possible to test and debug thisformalisation. This is important since a correct formalisation of the languagesemantics is a prerequisite for proving properties about programs and analysesconcerning dynamic properties of programs, something we believe is particu-larly important in the context of typical smart card applications. For exam-ple, in the framework of Java cards with several applications, we are startingsome work on static analysis of object sharing between applications [15]. Oneoutcome of this research could be a facility for statically detecting sharingviolations or the absence of such violations. Since a violation will cause anexception, it would clearly be reassuring to know that this cannot happen.Our environment provides a Java Card speci c editor. Thus the developer isassured that his code is Java Card code and is free from syntax error. Thisgreatly reduces the number of Java compiler and converter errors and savesdevelopment time. Thus our aim is not to build an environment ful llingcommercial requirements, but we do think it provides innovative features thatcould be integrated to existing environments in order to improve them.It still remains to include the complete set of APIs, and to support loadingapplets from more than one le. The current semantics is still missing a fewfeatures. This should be addressed. We would also like to further improvethe debugging support, for instance by making it possible to set breakpoints,single step, etc. at the Java Card source level. We also aim to integrate capa-bility for graphical object structure browsing along the lines found in Attali et18 al. [3]. Finally, it is planned to move towards a SmartTools 6 -based solution,SmartTools being the 100 % Java successor to Centaur.AcknowledgementsThe authors would like to thank Valérie Pascual for helping out with Centaur.References[1] J. Alves-Foss, editor. Formal Syntax and Semantics of Java, volume 1523 ofLecture Notes in Computer Science. Springer-Verlag, 1999.[2] I. Attali, D. Caromel, H. Nilsson, and M. Russo. From executable formalspeci cation to Java property veri cation. In Drossopoulou et al. [12], pages1 7.Available from www.informatik.fernuni-hagen.de/pi5/publications.html.[3] I. Attali, D. Caromel, and M. Russo. A formal and executable semantics for Java.In Proceedings of Formal Underpinnings of Java, an OOPSLA'98 Workshop,Vancouver, Canada, October 1998. Technical Report, Princeton University.ftp://ftp-sop.inria.fr/oasis/Marjorie.Russo/OopslaWorkshop98.ps.gz[4] G. Barthe, G. Dufay, L. Jakubiec, B. Serpette, S. Sousa, and S.-W. Yu.Formalization in Coq of the Java Card virtual machine. In Drossopoulou et al.[12], pages 50 56.Available from www.informatik.fernuni-hagen.de/pi5/publications.html.[5] P. Borras, D. Clément, T. Despeyroux, J. Incerpi, G. Kahn, B. Lang, andV. Pascual. Centaur: the system. In Proceedings of SIGSOFT'88, ThirdAnnual Symposium on Software Development Environments (SDE3), Boston,USA, 1988.[6] J. Castella, J. Domingo-Ferrer, J. Herrera, and J. Planes. A performancecomparison of java cards for micropayment implementation. In A. WatsonJ. Domingo-Ferrer, D. Chan, editor, Smart Card Research and advancedApplications Proceedings of CARDIS'2000, pages 19 38, Bristol, UK,September 2000.[7] Z. Chen. How to write a Java Card applet: A developer's guide. Java World,July 1999.http://www.javaworld.com/javaworld/jw-07-1999/jw-07-javacard_p.html6 http://www-sop.inria.fr/oasis/SmartTools19 [8] Z. Chen. Java Card Technology for Smart Cards Architecture andProgrammer'd Guide. The Java Series. Addison-Wesley, Sun Microsystems, PaloAlto, California, USA, 2000.[9] R. M. Cohen. Defensive Java Virtual Machine Speci cation version 0.5.Manuscript, 1997.[10] C. Courbis. Simulation d'applications Java Card.Rapport du DEA d'Informatique de Lyon (DIL),ftp://ftp-sop.inria.fr/oasis/publications/1998/CarineCourbisStageDEA0798.pdf, 1998.[11] S. Drossopoulou and S. Eisenbach. Describing the semantics of Java and provingtype soundness. In Alves-Foss [1], pages 41 82.[12] S. Drossopoulou, S. Eisenbach, B. Jacobs, G. T. Leavens, P. Müller, andA. Poetzsch-He ter, editors. Formal Techniques for Java Programs 2000.Technical Report 269, Fernuniversität Hagen, 2000.Available from www.informatik.fernuni-hagen.de/pi5/publications.html.[13] D. Hagimont and J.-J. Vandewalle. Jccap: Capability-based access control forjava card. In A. Watson J. Domingo-Ferrer, D. Chan, editor, Smart CardResearch and advanced Applications Proceedings of CARDIS'2000, pages 365388, Bristol, UK, September 2000.[14] L. Henrio. Tests interactifs d'applications Java Card.Rapport de stage d'option scientifique de l'école Polytechnique,ftp://ftp-sop.inria.fr/oasis/publications/1999/LudovicHenrioStageX0699.pdf, 1999.[15] L. Henrio. Analyse de partage pour applications Java Card. stage de DEA, 2000.[16] G. Kahn. Natural semantics. In Proceedings of Symposium on TheoreticalAspects of Computer Science, volume 247 of Lecture Notes in Computer Science,Passau, Germany, 1987.[17] J.-L. Lanet and A. Requet. Formal proof of smart card applets correctness.In J.-J. Quisquater and B. Schneier, editors, Third Smart Card Research andAdvanced Application Conference, Louvain-la-Neuve, Belgium, September 1998.[18] D. von Oheimb and T. Nipkow. Machine-checking the Java speci cation: Provingtype-safety. In Alves-Foss [1], pages 119 156.[19] Sun Microsystems. Java Card 2.1 platform.http://java.sun.com/products/javacard/javacard21.html, 1999.[20] D. Syme. Proving Java type soundness. In Alves-Foss [1], pages 83 118.[21] J.-J. Vandewalle and E. Vétillard. Developing smart card-based applicationusing Java Card. In Third Smart Card Research and Advanced ApplicationConference, 1998. http://www.gemplus.com/smart/r_d/publications/art1.htm20 A Source code for the Purse applet/**********************************************************************Purse Class*********************************************************************/import javacard.framework.*;class Purse extends Applet {protected final static byte PURSE_OP_CLA = (byte) 0xD0;protected final static byte PURSE_DEPOSIT = (byte) 0x01;protected final static byte PURSE_WITHDRAW = (byte) 0x02;protected final static byte PURSE_BALANCE_CHECK = (byte) 0x03;private final static short PURSE_MAX = (short) 0x7FFF;private short purseTotal;protected Purse() {purseTotal = (short) 0;}public static void install(byte[] bArray, short bOffset, byte bLength)throws ISOException {Purse myPurse = new Purse();myPurse.register();}public boolean select() {return true;}public void process(APDU apdu) throws ISOException {byte[] buffer = apdu.getBuffer();if (buffer[0] == PURSE_OP_CLA) {if (buffer[1] == PURSE_DEPOSIT)purseDeposit(apdu, buffer);elseif (buffer[1] == PURSE_WITHDRAW)purseWithdraw(apdu, buffer);else if (buffer[1] == PURSE_BALANCE_CHECK)purseBalanceCheck(apdu, buffer);} else if (selectingApplet()) {/* Do nothing. */}}/*********************** Private Methods ****************************/private void purseDeposit(APDU apdu, byte[] buffer) {int Lc = apdu.setIncomingAndReceive();short Le;short amountOfDeposit = Util.getShort(buffer, (short) 5);short temporaryPurseTotal = (short) (amountOfDeposit + purseTotal);if (amountOfDeposit > 0 && temporaryPurseTotal <= PURSE_MAX) {purseTotal = temporaryPurseTotal;Util.setShort(buffer, (short) 0, purseTotal);apdu.setOutgoingAndSend((short) 0, (short) 2);}}private void purseWithdraw(APDU apdu, byte[] buffer) {int Lc = apdu.setIncomingAndReceive();short Le;short amountOfWithdraw = Util.getShort(buffer, (short) 5);short temporaryPurseTotal = (short) (purseTotal amountOfWithdraw);if (amountOfWithdraw > 0 && temporaryPurseTotal >= 0) {purseTotal = temporaryPurseTotal;Util.setShort(buffer, (short) 0, purseTotal);apdu.setOutgoingAndSend((short) 0, (short) 2);}}private void purseBalanceCheck(APDU apdu, byte[] buffer) {Util.setShort(buffer, (short) 0, purseTotal);apdu.setOutgoingAndSend((short) 0, (short) 2);}}21